home *** CD-ROM | disk | FTP | other *** search
/ Aminet 5 / Aminet 5 - March 1995.iso / Aminet / comm / envoy / Envoy20FixInfo.lha / Envoy20FixedBugs
Text File  |  1995-02-05  |  33KB  |  554 lines
  1.  
  2. Information on the Enhancements and Fixed Bugs in Envoy 2.0
  3. ===========================================================
  4.  
  5. There were no small amount of questions on what has changed from Envoy
  6. 1.6 to the current Envoy 2.0 release. To answer these questions we
  7. decided to make our informal "FixedBugs" file publically available.
  8. Not only on the Envoy distribution disk, but also separately. This
  9. file has been created during the development process of Envoy 2.0. So
  10. be careful:
  11.  
  12.    ************************************************************************
  13.    *                                                                      *
  14.    *                            DISCLAIMER                                *
  15.    *                                                                      *
  16.    *   THIS SOFTWARE AND INFORMATION IS PROVIDED "AS IS".                 *
  17.    *   NO REPRESENTATIONS OR WARRANTIES ARE MADE WITH RESPECT TO THE      *
  18.    *   ACCURACY, RELIABILITY, PERFORMANCE, CURRENTNESS, OR OPERATION      *
  19.    *   OF THIS SOFTWARE AND INFORMATION, AND ALL USE IS AT YOUR OWN RISK. *
  20.    *   NEITHER COMMODORE NOR THE AUTHORS ASSUME ANY RESPONSIBILITY OR     *
  21.    *   LIABILITY WHATSOEVER WITH RESPECT TO YOUR USE OF THIS SOFTWARE     *
  22.    *   AND INFORMATION.                                                   *
  23.    *                                                                      *
  24.    ************************************************************************
  25.  
  26. While Envoy is of course not freely redistributable at all, you may
  27. distribute this informational file in unmodified form only if you want
  28. to. We sincerely hope you do so, as of course any further development
  29. of Envoy 2.0 depends on its commercial success.
  30.  
  31. If you want information on how to upgrade to, or obtain Envoy 2.0, please
  32. send email to <info@iam.com>.
  33.  
  34. Heinz Wrobel & Dale L. Larson
  35. Intangible Assets Manufacturing
  36.  
  37. /*------------------------------------------------------------------------*/
  38.  
  39. This is an internal, informal unedited list of fixed bugs, changes and beta
  40. notes during the 2.0 development process.  It is provided as a courtesy to
  41. developers and other power-users.  Please do not ask us questions about this
  42. list -- if you don't have a problem to report with 2.0 you don't have a
  43. problem.
  44.  
  45. Please also realize that most software has lists of fixed bugs at least
  46. this large -- they just usually aren't made public.  The large list
  47. doesn't mean that the software was unreliable or not useful for most users
  48. in previous versions.  Hopefully more software vendors will be more open,
  49. since openness provides more confidence to sophisticated users than it
  50. does scare people about the number of small bugs in typical software.
  51.  
  52. We no longer have a list of known bugs.  If we knew about them, we'd have
  53. fixed 'em.
  54.  
  55. Fixed bugs and changes since Envoy 1.6a
  56. =======================================
  57.  
  58. [Really important behaviour changes are marked with '!!']
  59.  
  60.     - Crash on aborting examines (C:LIST, CTRL-C).
  61.     - FindService() returning garbage error codes.
  62.     - GetHostName() appending LocalHost to the passed buffer for a NULL
  63.       enitity passed.
  64.     - Crashes in HostRequestA(). Lousy GUI code. Fixed for now. Should
  65.       be replaced.
  66.     - Repaired half a ton of "cast" bugs. Lots of code used
  67.       inappropriate and sometimes really destructive casts.
  68.     - NIPCBuffer trashing on local ACTION_READ and ACTION_WRITE.
  69.     - endless retry on security reject which in essence hangs the client
  70.       and loads the line.
  71.     - filesystem.service used to open after one failed open if
  72.       nipc.library was available, even if the other libraries needed
  73.       were not. Net result ==> GURU!
  74.     - ACTION_SET_FILE_SIZE should work now.
  75.     - hanging lock on security failure when trying to enter a directory.
  76.     - fs server left locks on failing mount requests for non existing volumes.
  77.     - on mount fs server reported "doesn't exist" when it in fact rejected the
  78.       user.
  79.     - server had serious problems with handling requester suppression on a
  80.       mount.
  81.     - ACTION_FH_FROM_LOCK works now.
  82.     - fcconfig deleted temporary ".info" file manually. It now uses
  83.       DeleteDiskObject().
  84.     - fsconfig did not really fit onto a 640x200 topaz 8 WB.
  85.     - The fs code and the fs prefs code duplicated many structures and
  86.       defines which should have been defined in one place only to avoid
  87.       compatibility breaks. Fixed now. Referencing includes across
  88.       directories is not nice but a lot better than duplicating their
  89.       contents arbitrarily. I need to do something about nipc, too.
  90.     - Cleaned out obsolete intuition identifiers where I found them.
  91.     - Groups prefs has now a better login.
  92.     - About menus added to the filesystem prefs editors.
  93.     - An english locale text for the nipc prefs was too long. Fixed.
  94.     - Small kludge added to nipc.library to have Envoy 1.65 behaviour on
  95.       the S2 CopyFromBuffer callback. Envoy 1.65 always returned success on
  96.       this callback no matter what. Hmm. DO NOT DEPEND ON THIS!
  97.     - Missing Permit() in FindEntity() code could potentially have stopped
  98.       the system.
  99.     - nipc S2 code could leave buffer lying around on low memory.
  100.     - nipc S2 code did not necessarily queue ARP requests again when
  101.       the remote side came back into service.
  102.     - internal nipc S2 packet counters for internal statistics were not
  103.       handled correctly. Doesn't matter for the user though. This
  104.       was more a cosmetic fix.
  105.     - nipc UDP closed connection via Forbid() protection while the list was
  106.       otherwise semaphore protected.
  107.     - nipc ARP buffer entry timeout value was wrong by a factor of 10.
  108.     - nipc doesn't depend on services.library internals anymore.
  109.       services.library V40(!) has special private access functions
  110.       now. services manager uses these for locking now, too.
  111.     - CreateEntityA() made the entity available before it was fully
  112.       initialised. If this was done just at the "right" time,
  113.       nipc.library would crash or do other strange things.
  114.     - nipc RDP made an active connection available on open before having
  115.       set up all data needed.
  116.     - gross bugs in nipc RDP handling. The headerlength was not set according
  117.       to RFC908 and on dataless "flag" packets the wrong sequence number
  118.       was used! Actually I am not sure if RDP works as described in
  119.       RFC908/1151 at all. The code looks more like "we do it not quite like
  120.       they do it" which really is annoying.
  121.     - dataless RDP packets updated the sequence number of the last ack'ed
  122.       packet to the current one even if there was no ack!
  123.     - nipc RDP data acceptance via PacketIn() had major problems:
  124.  
  125.         - If a needed packet in sequence did not arrive, it would continue
  126.           to queue even redundant packets until death.
  127.         - In two places it had search algorithms with an O(n^2) like
  128.           brute force approach to the problem. Hmpfh.
  129.         - it ack'ed segments but did not tell the timeout code that those
  130.           segments were acked. So the timeout code sent another ack.
  131.  
  132.       I rewrote this completely. No reasonable way to fix it without
  133.       throwing it out.
  134.     - nipc RDP code would in some cases either dereference NULL pointers
  135.       or other invalid list pointers, access closed (non existing!)
  136.       connections, or send spurious resets to the other side with garbage
  137.       sequence numbers.
  138.     - On closing nipc RDP connections in the listening state, the RDP code
  139.       sent a reset to some undiscovered country.
  140.     - nipc RDP resets were not necessarily obeyed.
  141.     - While checking on some nipc stuff I found that NIPCConfig would
  142.       really barf on you if you tried to use the Realm configuration
  143.       screen. As it turned out, someone used "mlh_Tail" instead of
  144.       "mlh_TailPred" for walking a list.
  145.     - nipc AMP code cleared out all the RDP flags when it had been
  146.       signaled on an available transmit window. '!' was used for inverting
  147.       a bit mask rather than '~' in three places scattered in
  148.       BeginTransaction() and ReplyTransaction()! A sure killer IMHO.
  149.       The same bug was in DeleteEntity() in handling entity flags.
  150.       Just wondering: How did nipc work at all? ;^) :-(
  151.     - nipc RDP will now flush still pending writes when they are
  152.       acknowledged, not only on a timeout run after it has timed out!
  153.     - On startup nipc will do better checking of any sana2 device it tries
  154.       to open. This fixes e.g. an open amoksana.device with no HW
  155.       connected.
  156.     - If a sana2 device goes into "failure mode" and barfs on any and
  157.       all requests for some reason, nipc.library would hog the CPU
  158.       and in effect lock the system. Error handling tries to be
  159.       smarter now, even though there is no true general solution to
  160.       the problem. This should help in most cases, though.
  161.     - FindEntity() messed with an entity after releasing the entity list
  162.       semaphore. Tiny window, but a window.
  163.     - password hook in the login requester fixed. Now it is possible to
  164.       delete a password that is too long and retype it.
  165.     - printer prefs and Users are now localised.
  166.     - Strange double click behaviour in Filesystem Imports ListView
  167.       fixed.
  168.     - fixed potential holes in nipc sana 2 code that could have messed up
  169.       sana 2 addresses with a bit count that is not a multipe of eight.
  170.     - nipc sana 2 code did not clear allocated IORequest memory in all
  171.       cases. This could have caused strange flag settings etc.
  172.  !! - nipc ARP will now be used for all HW types, not just for
  173.  !!   ethernet connections. This is an incompatible change but fixes
  174.  !!   the HW address vs. IP address dependency problems.
  175.  !! - If the user chose defaults for IP and ARP type in the network
  176.  !!   configuration for a device, he will get ethernet values 2048 and 2054
  177.  !!   unless ARCNET is used. Then 240 and 241 are used as defaults
  178.  !!   in nipc.library. While this is not a good solution at all as it
  179.  !!   doesn't take into account the actual HW available, it will at
  180.  !!   least give reproducible results compared to the "ignore the
  181.  !!   checkmarks and take whatever we have" type of behaviour.
  182.     - There is a major conceptual problem with RDP sequence number wrap
  183.       around. This always has and still does completely confuse the RDP
  184.       code and will in effect make the RDP connection affected unusable and
  185.       probably flood the net with packet retransmits that are never
  186.       correctly acknowledged. I am in the process of doing something about
  187.       this, but this is a _very_ tricky subject. Hopefully my rework
  188.       of sequence number handling works. This needs more testing.
  189.     - With my RDP rework I added a new bug affecting the start up of a
  190.       connection. For fixing this bug I did some heavy RDP debugging.
  191.       So RDP connections should work a lot better now. Especially
  192.       starting up an RDP connection should be now as fast as it used
  193.       to be again. Again, the new release might be incompatible to
  194.       previous buggy releases. Sorry for the inconvenience. We are now
  195.       at nipc.library 40.18.
  196.     - Changed the printspool.service naming convention for jobs from
  197.       "t:job%ld" to "T:EnvoyPrintJob_%ld" to avoid any conflicts.
  198.     - Services Configuration should no longer leave filelocks or library opens
  199.       hanging! It will also default to "/Services" now as directory for
  200.       adding services (it is based in Configurations!). This should help
  201.       poor B. J. User somewhat.
  202.  
  203.     - Back to the filesystem. ACTION_READ_LINK returned DOSTRUE and
  204.       ERROR_ACTION_NOT_KNOWN for some strange reason. Fixed. This shouldn't
  205.       have been a problem anyway as ReadLink() should only be called if
  206.       ERROR_IS_SOFT_LINK has been returned by the FS, which of course
  207.       cannot happen.
  208.     - Found a hole in internal restarts of ExAll type requests.
  209.       Packets were added to the head of the main FS packet port
  210.       without any protection at all!
  211.     - ACTION_MAKE_LINK will now work for hard links. This might
  212.       e.g. help DUUCP users with a networked news tree.
  213.     - I decided to finally try it: Record locking should work now.
  214.       This needs more testing though for reliability.
  215.     - ACTION_DELETE_OBJECT may take a lot longer for large files than
  216.       pretty much any other packet. So the default timeout of 6
  217.       seconds was not enough and even though the packet succeeded, the
  218.       network transaction timed out. I bumped the timeout to 18
  219.       seconds for a delete. This stuff shouldn't be done via a single
  220.       transaction, but it is not at all easy to rewrite!
  221.       Bumping the timeout is not a solution but it'll make the situation
  222.       at least a lot better for most users.
  223.     - Really nasty bug on reconnect of a broken network mount. The
  224.       client passed the full server path of the object in question
  225.       without the server drive specifier. This could lead to write
  226.       files popping up in strange places suddenly and read files not
  227.       to reconnect. Same problem fixed for locks.
  228.     - ACTION_READ/ACTION_WRITE could still leave buffers lying around on
  229.       failure. Should be fixed now.
  230.     - ACTION_READ/ACTION_WRITE would pretty much garble the client seek
  231.       position on network failure or partial R/W failure. Now a bona fide
  232.       attempt is done to keep the seek position correct. This might still
  233.       fail of course, but this is better than not doing anything at all
  234.       about it.
  235.     - While an ACTION_READ/ACTION_WRITE is pending all incoming packets for
  236.       this file handle are saved and queued again after the R/W is
  237.       complete. The packets were requeued in reversed order and without
  238.       sufficient list protection.
  239.     - I found a reproducible case where after a reconnect the client was
  240.       accessing the root of the mounted server drive where the network
  241.       volume is located, and not the root of the network volume.
  242.     - The server did not clean up exall handling for locks discarded on
  243.       a dead mount.
  244.     - The client/server had an internal concept of a -1 lock which
  245.       represented the current server directory on reconnect. No code
  246.       used this feature for anything useful and it messed up
  247.       reconnections with volume relative paths. I took it out.
  248.       Reconnect works volume base relative now.
  249.     - ACTION_EXAMINE_ALL was commented out on the client side. Why? Because
  250.       it was totally and absolutely f...ouled up in many subtle ways
  251.       on both the client and server side. It should work now. Please
  252.       test this and all the bells and whistles like eac_MatchFunc in
  253.       detail. Why I did all this work? Because EXAMINE_ALL and all the
  254.       other examine functions share common code. So I had to fix it.
  255.     - ACTION_EXAMINE_NEXT could be ended prematurely, pulling out the rug
  256.       under the client while doing this.
  257.     - The server tried to filter filenames in the examine calls even
  258.       if there was no buffer space set up.
  259.  
  260.     - Did some autodoc typo fixes in nipc.library.
  261.     - Tiny change in nipc.library's buffer handling. What is
  262.       externally visible as AppendNIPCBuff() will now move the list of
  263.       buffer entries in one piece instead of entry after entry. This
  264.       saves some CPU time. I improved this on the way as I found a
  265.       possible cause for an enforcer hit in low memory situations.
  266.       Found this due to a bug report on nipc enforcer hits that were
  267.       actually caused by the fs code.
  268.     - With the fs update, I introduced a bug in R/W buffer handling
  269.       that could cause enforcer hits in nipc.library under certain
  270.       network failure situations. Fixed, hopefully.
  271.     - Interesting enough, I cultivated a bug in exall handling when
  272.       redoing the exall stuff. The matchstring was passed to the
  273.       server to filter entries. While this is in theory a neat idea
  274.       by the C= guys to save on the actual transfer, it doesn't work
  275.       as I know now. Preparsed patterns are not portable between
  276.       different dos.library versions. Now all the filtering is done on
  277.       the client side. This is unfortunately much less efficient.
  278.     - Another bug was in filtering of exall entries on the client
  279.       side. It did not remove entries correctly in all cases.
  280.  
  281.     - The sana2 code in nipc.library could "forget" to requeue packets for
  282.       ARP under certain conditions. It also queued read packets for devices
  283.       known to be offline which is totally useless and hogs the CPU.
  284.     - Slight rework of R/W packet handling to be on the safe side. I
  285.       _think_ I found the hole causing spurious enforcer hits via
  286.       nipc.library once in a while, but I am not sure yet.
  287.  
  288.     - "Network Configuration" will no longer force the realm
  289.       checkboxes set, just because there are entries in the realm
  290.       lists. This makes it possible to turn off a realmserver without
  291.       loosing the entered prefs data.
  292.     - It should be possible now to use the RETURN key in the "Network
  293.       Configuration" "Host Configuration" panel to hop from gadget to
  294.       gadget just like with all the other panels.
  295.     - There is still a bug in the RDP code when a packet sequence number
  296.       wrap around occurs. I found this based on a hunch regarding the
  297.       "overnight hanging bug". This bug in effect breaks the
  298.       connection. I have started to investigate and fix this, and as a
  299.       result the new nipc.library will once again be absolutely
  300.       incompatible to previous versions. Sorry. A side effect of my
  301.       work for a fix is that some fields are now 32 bit aligned which
  302.       should help on anything >=68020, i.e. >= A1200.
  303.     - Sequence number wraparound should be ok now. Finally.
  304.     - Fixed a few holes in the RDP code where a task waiting on RDP
  305.       permission to send stuff would sleep forever. When this happened
  306.       due to the sequence number wrap around bug, this connection
  307.       would effectively hang. This should explain and fix the
  308.       "overnight hangs" for good. I hope there isn't more of this.
  309.       We are now at nipc.library 40.24.
  310.  
  311.     - Note that nipc will not use trans_Timeout for local transactions
  312.       currently. So a local entity connection will hang if the
  313.       destination hangs. The source has no chance to recover. I feel
  314.       that this is a bug (which is currently hard to fix). What do you
  315.       think? COMMENTS ARE WELCOME!
  316.     - The server could show erratic behaviour if you sent paths longer than
  317.       128 characters to ACTION_LOCATE/DELETE_OBJECT and ACTION_CREATE_DIR.
  318.     - ACTION_SET_DATE would return garbage results on a security failure.
  319.     - ACTION_CHANGE_MODE was flaky with filehandles before. Should work now.
  320.     - fs server locked a semaphore a few lines to late. No problem with
  321.       normal use, but still a bug.
  322.     - On cleaning up dead mounts, the server left a lock lying around.
  323.     - The client was flaky with timeout settings on reconnect. This could
  324.       hang a reconnect.
  325.     - Unlocking NULL locks is not nice, but should be regarded as ok. This
  326.       is now the case.
  327.     - Believe it or not, I found another nipc bug. If you deleted a public
  328.       entity that still had connections pending, it would be silenced as
  329.       far as possible, but not be made private. This would lead to enforcer
  330.       hits if a remote side tried to enumerate entities. As a side effect of
  331.       my fix, FindEntity() will now behave according to spec and only find
  332.       local entites if they were created with ENT_Public, just like with
  333.       remote entities. We are now up to nipc.library 40.25. How many
  334.       revision will there be?
  335.     - ACTION_DELETE_OBJECT will now run async on the server. It should
  336.       no longer block server activity for other clients until the
  337.       delete is done. The client will get a response when the delete is
  338.       done, but the server is not locked up for other clients in the
  339.       meantime.
  340.     - The client is now a little better about doing at least one retry with
  341.       a prolonged timeout itself before putting up a requester. So
  342.       timeout requesters will come later now.
  343.     - EFS should behave _much_better_ now with server drives having RMS. It
  344.       used to barf in many ways, now it should handle this rather
  345.       gracefully and hopefully do the right thing in all cases. As this
  346.       needs truly tons of testing, I hesitate to say that Envoy has RMS
  347.       now. While the mounts on the client turn up as public entities now,
  348.       it won't make any sense for a user to FindEntity() them. They are
  349.       public only to let the server be able to contact them in majik wayz.
  350.       Please try this with CDx: and DFx: and whatever you got. Note that
  351.       RMS does not carry across machines. You can't export a volume in
  352.       df0:, get locks on it on the client, move the disk physically to the
  353.       client's disk drives and expect it to be recognized.
  354.  !! - A BEHAVIOUR CHANGE of fs exports. An export with an empty export
  355.  !!   name used to get the clients device mount name. Now it will get
  356.  !!   the true volume name of the servers volume. This makes much more
  357.  !!   sense and an empty name is now the preferred setting for
  358.  !!   exporting a DOS device with RMS. Actually it is probably
  359.  !!   reasonable to say a few things about RMS name handling and
  360.  !!   reconnect behaviour now. As described above the client used to
  361.  !!   have the same name for the volume node as for the client's
  362.  !!   device node if no export name was specified on the server. This
  363.  !!   was not logical, as both the export and import prefs listed the
  364.  !!   server's export path (typically a device name) in this case. In
  365.  !!   this case the client can make much more use of the server's
  366.  !!   volume name. All this does not affect name use of the client at
  367.  !!   all, as of course the device node is still there and any
  368.  !!   reference to that name will now go via the device node instead
  369.  !!   of the volume node. Nothing is lost. The client just has
  370.  !!   additional information available via the correct volume node.
  371.  !!   RMS and reconnect are related to the above. If an export name is
  372.  !!   configured on the server, it will be only used on a mount of an
  373.  !!   inserted volume or a reconnect (which is in effect a remount).
  374.  !!   If no name is configured the true volume name will be used. For
  375.  !!   any disk change, only the true volume nname will be used. Why?
  376.  !!   because having different active volumes with all the same name
  377.  !!   doesn't make much sense. So there is one simple rule now: If you
  378.  !!   export a drive/device with RMS, don't specify an export name.
  379.     - the server should no longer work with garbage guid/uid's on low
  380.       memory situations.
  381.     - I got tired of rebooting, so now the server supports file
  382.       notification on its prefs file in ENV:. One can change the
  383.       export configuration on the fly now. The Services Manager
  384.       will also try to reload its configuration now if it has been
  385.       changed. Note that this cannot (and probably should not) be done
  386.       easily for nipc due to how all the stuff works.
  387.     - Added a "Use" button to the fs export prefs and appropriate menu
  388.       headers to select env: or envarc: values. Default is empty.
  389.     - Services Prefs behaved strange when using the "Last Saved" menu.
  390.       It appended the stuff to the current list of services.
  391.     - Notification should be working now. Some special notes about
  392.       this, though:
  393.         a) Any action done through EFS that should cause a
  394.            notification of the client, will cause one (Guru Book!).
  395.            The ROM fs and RAM handler don't do it that way.
  396.         b) Any action done through the server fs will cause a
  397.            notification if that fs supports notification for the
  398.            action. Needed to get notifed of other's accesses.
  399.         c) As a result, any action done through EFS will cause
  400.             1 notification event if only EFS supports it, and
  401.             2 notification events if both EFS and the server fs
  402.             support it.
  403.       While two events can be annoying at times, they are better than
  404.       none at all. I have no way to tell which actions on the server
  405.       side fs will cause a notification by that fs and which won't.
  406.       Please test this with both signal and message notification and
  407.       whatever flags there are, and with reconnect!
  408.     - The login requester password hook was a pain. I removed editing
  409.       restrictions now to make it work. For users that get lost in
  410.       typing in dots this means, they probably better kill the contents
  411.       and retype in some cases.
  412.     - The printer server should now process spooled client files in 8k
  413.       chunks instead of 1k chunks. This _might_ help efficiency.
  414.     - ACTION_WRITE_PROTECT is supported now. It will leave the server
  415.       untouched and do only client side write protection.
  416.     - Another change for ACTION_DELETE_OBJECT. While it doesn't block
  417.       server operation anymore for other mounts, all packets for the
  418.       client mount of the delete will be queued until the delete is
  419.       done and processed afterwards. Why? To guarantee sequential
  420.       behaviour in packet processing. Note: PLEASE TEST THIS! Maybe by
  421.       sending of an async delete packet and sending other packets
  422.       before the reply comes in. I don't trust my own tests at all
  423.       here. This stuff is tricky.
  424.     - String gadgets in Login/Host requester will be activated on
  425.       window activation.
  426.     - String gadget contents in Host requester will now be used even if
  427.       it wasn't deactivated by TAB/ENTER.
  428.     - I decided not to do anything about the string gadgets in Network
  429.       Configuration, Users, and Groups. This doesn't hurt too much and
  430.       would require some rewrite.
  431.     - I think I found the "split file on reconnect" bug. Finally. A
  432.       baselock for a path of a file to open was assumed to be the
  433.       parent lock of the file itself. So any path specs in the file
  434.       name got lost on the way which messed up paths for reconnect.
  435.     - As Dale correctly said, the printer stuff is FUBAR. Unless there
  436.       are any error reports, I probably won't touch it again. it needs
  437.       to be rethought and rewritten from scratch.
  438.     - Due to all the changes outlined above, I decided to call this
  439.       Envoy 2.0, not 1.8.
  440.  
  441.     - Services Configuration has now "Enabled:" again as english label
  442.       for the checkbox. For <V39 systems, I removed the display of the
  443.       currently selected service under the listview. There was no
  444.       reasonable way to get it to look nice on < 3.0 and >= 3.0.
  445.       This type of "bug fix" has been done to some other prefs editors
  446.       previously by C=. Probably for the same reason. It doesn't hurt
  447.       the user interface though. While doing this I found that
  448.         a) memory was left lying around when adding a bad service
  449.         b) an asl requester was freed twice while another wasn't freed
  450.            at all on exit. Automatic reboot included.
  451.       We are now at 37.13.
  452.     - Enforcer hit in nipc.library fixed. I introduced this bug with
  453.       my fixes for 40.25. Now we are at 40.26.
  454.     - A minor problem with notification in the fs server. Notification
  455.       was not done for the parent directory of the modified object.
  456.       Notification for objects referenced with a lock and an empty
  457.       file name could have been flaky. This should be ok now. I did
  458.       not mention one other thing before: Notification should
  459.       theoretically be done on all the hard links of the modified
  460.       object, too. If you think about it hard, you will realise that
  461.       this is not possible. This is not a bug. Anyway, the server is
  462.       now up to 40.29.
  463.     - This is embarassing. I left in debugging code that delayed a
  464.       notification setup for > 1 second. Server is now at 40.30.
  465.     - The AmiCDRom filesystem doesn't seem to set up its struct Resident
  466.       correctly. This caused hits on volume insertion. I put a kludge into
  467.       the fs server to compensate for this problem. Now at 40.31.
  468.     - The client sets the DiskType in the volume nodes now. This should
  469.       help "Filesystem Imports" to decide on already mounted mounts. Now at
  470.       40.41.
  471.     - Minor typo fixes in some doc files and minor german locale update.
  472.     - Filesystem Imports complained on empty drives even if the mount was
  473.       ok. Fixed. It should be a lot better about determining which drives
  474.       are already mounted, too. The original code had "crashy" tendencies
  475.       for removable media and did not take device mounts into account.
  476.       Now at 40.9.
  477.  
  478.     - Filesystem Imports will now check only active Envoy mounts to
  479.       see if they are already mounted. Inactive mounts should be left
  480.       alone for sure, now. Now at 40.10
  481.     - The efs client did some filehandle init it should not have done.
  482.       Now at 40.42.
  483.     - The efs client could give enforcer hits if someone did an UnLock()
  484.       right after an Examine()/ExNext() in just the right timing. A lock
  485.       was freed twice and invalid memory way referenced in that case. Also
  486.       freeing a ZERO lock could probably result in unusual behaviour.
  487.       As all the lock handling code turned out to have some perfectly
  488.       valid, but obscure areas from the simple readability point of view, I
  489.       did some beautification work in addition to fixing things.
  490.       And while this is very ugly behaviour of any application, efs
  491.       should now be robust against "copied" locks. This last thing is
  492.       mainly a paranoia fix triggered by my research on the exnext problem
  493.       which started this. Now at 40.43.
  494.     - Found some places where lock pointers were set up without a
  495.       check for the BPTR to be ZERO. This was always ugly and is
  496.       deadly now. The efs client is up to 40.44 now.
  497.     - nipc should no longer try to write to sana 2 devices which are
  498.       definitely known to be offline. This should be cosmetic though. I am
  499.       still not clear on what is causing problems with ppp.device. But
  500.       maybe this reduction of io helps finding the actual problem. Now at
  501.       40.27.
  502.     - After some thought I decided to modify the sana 2 device init in nipc
  503.       to complain loud on any problems. I assume now that the user wants
  504.       those devices she specified in Network Configuration to work well.
  505.       Previously only a failure to open a device at all caused an
  506.       requester to pop up. Now any "fatal" error which will prohibit nipc
  507.       from setting up and using a device will generate a requester. This
  508.       should reduce the "doesn't do anything after boot" problems
  509.       without user notification by about 100%. And it should help fix
  510.       bugs as you will get to see an error number. nipc.library is now
  511.       at 40.28.
  512.  
  513.     - The EFS client returned ERROR_WRITE_PROTECTED instead of
  514.       ERROR_DISK_WRITE_PROTECTED on an active ACTION_WRITE_PROTECT.
  515.       This is fixed now and the EFS client is now at 40.45.
  516.     - Bumped some versions to allow for a decent HWGRCS version freeze
  517.       for release. I was unfortunately lazy sometimes. No change in
  518.       functionality at all. Just a recompile with a new version number.
  519.         filesystem.service:         40.32
  520.         Filesystem Imports:         40.11
  521.         Filesystem Exports:         40.9
  522.         nipc.library:               40.29
  523.         envoy.library:              37.21
  524.         services.library:           40.2
  525.  !! - I have a hunch concerning the ppp.device problem. It is now
  526.  !!   possible to disable ARP by setting the ARP type to the IP type.
  527.  !!   It counts as unsupported hack, though. I am not sure it will stay
  528.  !!   that way. This does not affect compatibility as it is a normally
  529.  !!   illegal combination of values anyway. Maybe ARP was the problem.
  530.  !!   If this was truly the problem, we need to either document this
  531.  !!   way to turn off ARP or find a more intuitive way to do this
  532.  !!   for the user. Hmm. What about an ARP type of 0 to turn off ARP?
  533.  !!   Hmm. Let's wait on feedback. nipc.library is now at 40.30.
  534.     - The list of services was not correctly locked by nipc during an
  535.       inquiry. This could lead to overwritten memory, crashes or similarly
  536.       nasty things when the list changed at just the right time while an
  537.       inquiry was active. nipc.library is now at 40.31.
  538.     - The host requester in envoy.library had rather high stack usage. This
  539.       should be better now. It could also mess up the system if you
  540.       specified to many matchtags. This should be better, too. Now at
  541.       37.23.
  542.     - Filesystem Imports had rather high stack usage, too. It also
  543.       allocated a VisualInfo and never ever freed it. Now at 40.12.
  544.  
  545.  !! - Ok, this is it. The IMHO last change before releasing Envoy 2.0.
  546.  !!   The official way to turn ARP off is to set the ARP type to 0
  547.  !!   now. nipc.library is now at 40.32.
  548.  !!   Not all sana 2 drivers can transmit ARP packets. ARP is
  549.  !!   usually useful on Ethernet, and maybe on ARCNET or amoknet.
  550.  !!   For other sana 2 devices, refer to the respective documentation.
  551.  
  552. *** End Of Text ***
  553.  
  554.